System and method for using network layer uniform resource locator routing to locate the closest server carrying specific content

ABSTRACT

A request for an information object at an address identified by a uniform resource locator (URL) is received; and the URL is mapped to a corresponding anycast address for the information object. Thereafter, the anycast address for the information object may be resolved to a unicast address for the information object, and the information object sent to the client. The request may be received at an information object repository that is topologically closer to the client than any other information object repository. This closest information object repository may be selected according to specified performance metrics, such as: average delay from the selected information object repository to a source of the request, average processing delay at the selected information object repository, reliability of a path from the selected information object repository, available bandwidth in said path, and loads on the selected information object repository.

RELATED APPLICATIONS

The present application is related to U.S. provisional patentapplication No. 60/200,404, filed Apr. 28, 2000, entitled System andMethod for Using a Mapping Between Client Addresses and Addresses ofCaches to Support Content Delivery.

The present application is also related to U.S. provisional patentapplication No. 60/200,401, filed Apr. 28, 2000, entitled System andMethod for Discovering Information Objects and Information ObjectRepositories in Computer Networks (Wild Protocol).

The present application is also related to U.S. provisional patentapplication No. 60/200,511, filed Apr. 28, 2000, entitled System andMethod for Using URLs to Map Application Layer Content Names to NetworkLayer Anycast Addresses.

The present application is also related to U.S. provisional patentapplication No. 60/200,402, filed Apr. 28. 2000, entitled System andMethod for Using Network Layer (NURL) Routing to Locate the ClosestServer Carrying Specific Content.

The present application is also related to U.S. provisional patentapplication No. 60/200,403, filed Apr. 28, 2000, entitled System andMethod for Resolving Network Layer Anycast Addresses to Network LayerUnicast Addresses (AARP).

The present application is also related to U.S. patent application No.09/810,148, filed Mar. 15, 2001, entitled System and Method forDiscovering Information Objects and Information Object Repositories inComputer Networks which issued as U.S. Pat. No. 7,162,539 B2.

The present application is also related to U.S. patent application No.11/499,182, filed Aug. 3, 2006, entitled System and Method forDiscovering Information Objects and Information Object Repositories inComputer Networks.

The present application is also related to U.S. patent application No.09/843,789, filed

Apr. 26, 2001, entitled System and Method for Using a Mapping BetweenClient Addresses and Addresses of Caches to Support Content Delivery,which issued as U.S. Pat. No. 7,565,450 B2.

The present application is also related to U.S. patent application No.09/845,088, filed Apr. 26, 2001, entitled System and Method forControlling to Content Carried in a Caching Architecture, which issuedas U.S. Pat. No. 7,577,754 B2.

The present application is also related to U.S. patent application No.09/844,759, filed Apr. 26, 2001, entitled System and Method forResolving Network Layer Anycast Addresses to Network Layer UnicastAddresses, which issued as U.S. Pat. No. 7,725,596 B2.

The present application is also related to U.S. patent application No.09/844,857, filed Apr. 26, 2001, entitled System and Method for UsingUniform Resource Locators to Map Application Layer Content Names toNetwork Layer Anycast Addresses, which issued as U.S. Pat. No. 7,343,422B2.

FIELD OF THE INVENTION

The present invention relates to a system and method for the discoveryof information objects and servers storing information objectsdistributed over computer networks. More particularly, the presentinvention provides a system and method for using network layer uniformresource locator routing to find a topologically close informationobject repository storing a specified information object.

BACKGROUND

An internetwork is a collection of computer networks interconnected bynodes, each such node may be a general-purpose computer or a specializeddevice, such as a router. As such, an internetwork is often called anetwork of networks. The purpose of building an internetwork is toprovide information services to end nodes; each end node may be ageneral-purpose computer or a specialized device, such as a camera or adisplay. The Internet is an internetwork in which information isorganized into packets to be distributed on a store-and forward mannerfrom source to destination end nodes, and in which routers and end nodesuse the Internet Protocol (IP) to communicate such packets.

The World Wide Web (also known as WWW or Web) has become an essentialinformation service in the Internet. The Web constitutes a system foraccessing linked information objects stored in end nodes (hostcomputers) all over the Internet. Berners-Lee wrote the originalproposal for a Web of linked information objects (T. Berners-Lee,“Information Management: A Proposal,” CERN Document, March 1989). TheWeb consists of a vast collection of information objects organized aspages, and each page may contain links to other pages or, moregenerally, information objects with which content is rendered as audio,video, images, text or data. Pages are viewed by an end user with aprogram called a browser (e.g., Netscape Navigator). The Web browserruns in an end system at the user premises. The client (Web browser)obtains the required information objects from a server (Web server)using a request-response dialogue as part of the Hypertext TransferProtocol (HTTP). Information objects are identified by means of namesthat are unique throughout the Internet; these names are called UniformResource Locators or URLs. A URL consists of three components: theprotocol or scheme to be used for accessing the object (e.g., http), thename (a DNS name) of the host on which the object is located, and alocal identifier that is unique in the specified host.

Like any large-scale system, the Web requires the use of mechanisms forscaling and reliability. More specifically, as the number of informationobjects that can be obtained through the Web increases, people find itmore difficult to locate the specific information objects they need.Furthermore, as the number of Web users and servers increase, the sitesor servers that store the requested information objects may be very farfrom the users requesting the objects, which leads to long latencies inthe access and delivery of information, or the servers storing theinformation objects may be overwhelmed with the number of requests forpopular information objects.

It was clear soon after the birth of the Web that the simpleclient-server architecture underlying the Web protocols would not scaleto the number of clients and servers and volume of traffic thepopularity of the Web would be demanding very soon. To address thisimpending crisis research efforts were started, that continue today, todevelop solutions to this scaling problem based on the cache model usedin other areas of computer science. In general, the results of theseefforts have taken the form of caching proxy servers that intercept Webrequests destined for Web servers in the Internet, and attempt toservice these requests from a cache of objects retrieved for previousrequests. In the event of a cache miss the origin server is contacted,the content loaded to the cache, and the client's request is thensatisfied. As with all cache-based systems the goal of these solutionsis to replace many expensive, slow data fetches with one expensive, slowfetch and many fast, cheap ones. As will be reviewed below, this effort,while regularly facing new challenges and dilemmas, has generally madesteady progress towards providing a solution to the problem of theaccess and delivery of Web content that can scale to the global reachnow envisioned for the Web.

To enable the Web to scale to support large and rapidly increasingnumbers of users and a vast and growing collection of informationobjects, the information objects in the Web must be stored distributedlyat multiple servers, in a way that users can retrieve the informationobjects they need quickly and without overwhelming any one of theservers storing the objects. Accordingly, distributing informationobjects among multiple sites is necessary for the Web to scale and bereliable. The schemes used to accomplish this are called Web cachingschemes. In a Web caching scheme, one or multiple Web caches or proxyWeb servers (information object repositories, which term can alsoencompass origin content servers) are used in computer networks and theInternet to permit multiple host computers (clients) to access a set ofinformation objects from sites other than the sites from which thecontent (information objects or just objects) are provided originally.Web caching schemes support discovering the sites where informationobjects are stored, distributing information objects among the Webcaches, and retrieving information objects from a given Web cache. Themany proposals and implementations to date differ on the specificmechanisms used to support each of these services.

Reflecting the growing importance of the Web as an infrastructuretechnology, a Web caching industry has appeared and prospered in recentyears. Initially the products of this industry were caching proxyservers for use by organizations connected to the Internet that wantedto both reduce the utilization of their expensive ISP services, and toimprove the Web browsing experiences of their users. More recently,however, a new segment of this industry has evolved that serves theneeds of the Web server providers. These services, typically called Webcontent delivery services, involve the hosting of Web content for a fee.These services allow Web server providers to deploy content whosepopularity attracts larger audiences than can be supported by theirexisting Web server infrastructure without having to perform theexpensive upgrades to their server and network infrastructure that wouldotherwise be required. This has proven to be a lucrative segment of theWeb caching industry and has changed a number of fundamental assumptionsmade by previous research in developing Web caching solutions.

The traditional approach to Web caching, called client-directed Webcaching here, has made the fundamental assumption that Web caching wasdone by, and for the benefit of Web users. As a result, the designs ofWeb caching solutions developed to date have been based on a number ofconcrete assumptions, such as the following:

-   -   (1) the cache server used by a client is configured statically        or quasi-statically;    -   (2) the caching infrastructure is owned and deployed by many        organizations and therefore must inter-operate over the open        Internet; and    -   (3) the number of URLs served is unknown.

In contrast, the assumptions that can be made by these new Web cachingservices, called server-directed Web caching here, are significantlyless restrictive, such as the following:

-   -   (1) the cache used by a client is determined dynamically;    -   (2) the caching infrastructure is owned and deployed by one        entity, and can have non-standard components; and    -   (3) the number of URLs served is known.

It seems clear that these new assumptions provide significant newlatitude in the design of a Web caching service that may allow forsignificantly more efficient solutions than those developed based on themore restrictive assumptions underlying the previous client-directedsolutions.

Web caching proxies intercept Web requests destined for Web servers inthe Internet (thus the name “proxy”), and attempt to service theserequests from a cache of objects retrieved for previous requests (thusthe name “caching”). In the event of a cache miss the origin server iscontacted, the content loaded to the cache, and the client's request isthen satisfied. These early efforts involved stand-alone caches (AriLuotonen, Henrik Frystyk Nielsen, and Tim Berbers-Lee. Cern httpd.http://www/w3/org/Daemon, July 1996), whose only source of content on acache miss was the original content server. While somewhat effective atlightening the load on Web servers and the network infrastructure, itquickly became clear that standalone caches presented a new dilemma:while the hit rate experienced by a cache improves as the number ofclients using the cache grows, so does the cache server's load. Theeffectiveness of web caches at reducing server and network load waslimited by the compute and I/O power of the cache servers. While thepower of these servers was growing, it was not growing as fast as thevolume of Web traffic. Therefore it was clear that, while standalone Webcaches might delay the day of reckoning, they would not be able toeliminate it.

On realizing this in the 1995-96 time-frame, researchers began workingon solutions to allow multiple Web caches to cooperate in servicing alarger set of clients. It was hoped that the ability to support a largeand scalable set of clients would provide a long-term solution to Webserver and network overload.

Many methods exist in the prior art for determining the server, cache,mirror server, or proxy from which information objects should beretrieved. The prior art dates to the development of the ARPANET in the1970s and the study and implementation of methods to solve the fileallocation problem (FAP) for databases distributed over the ARPANET andcomputer networks in general.

File allocation methods for distributed databases (e.g., W. W. Chu,“Optimal File Allocation in a Multiple Computer System,” EEETransactions on Computers, October 1969; S. Mahmoud and J. S. Riordon,“Optimal Allocation of Resources in Distributed Information Networks,”ACM Transactions on Data Base Systems, Vol. 1, No. 1, March 1976; H. L.Morgan and K. D. Levin, “Optimal Program and Data Locations in ComputerNetworks,” Communications of the ACM, Vol. 20, No. 5, May 1977) anddirectory systems (e.g., W. W. Chu, “Performance of File DirectorySystems for Data Bases in Star and Distributed Networks,” Proc. NationalComputer Conference, 1976, pp. 577-587; D. Small and W. W. Chu, “ADistributed Data Base Architecture for Data Processing in a DynamicEnvironment,” Proc. COMPCON 79 Spring) constitute some of the earliestembodiments of methods used to select a delivery site for accessing afile or information object that can be replicated at a number of sites.

Another example of this prior art is the method described by Chiu,Raghavendra and Ng (G. Chiu, C. S. Rahgavendra, and S. M. Ng, “ResourceAllocation with Load Balancing Consideration in Distributed ComputingSystems,” Proc. IEEE INFOCOM 89, Ottawa, Ontario, Canada, April 1989,pp. 758-765). According to this method, several identical copies of thesame resource (e.g., a file, an information object) are allocated over anumber of processing sites (e.g., a mirror server, a cache) of adistributed computing system. The method attempts to minimize the costincurred in replicating the resource at the processing sites andretrieving the resource by users of the system from the processingsites.

Several different approaches exist in the prior art for discoveringinformation objects in Web caching schemes. Recent work has addressedthe same resource allocation and discovery problems within the contextof Internet services. Guyton and Schwartz (J. D. Guyton and M. F.Schwartz, “Locating Nearby Copies of Replicated Internet Servers,”Technical Report CU-CS-762-95, Department of Computer Science,University of Colorado-Boulder, February 1995; Proc. ACM SIGCOMM 95Conference, Cambridge, Mass., August 1995, pp. 288-298) describe andanalyze server location techniques for replicated Internet services,such as Network Time Protocol (NTP) servers and Web caches. Guyton andSchwartz propose gathering location data with router support in twoways. In one method, routers advertise the existence or absence ofreplicated servers as part of their normal routing exchanges involvingnetwork topological information. Routers examine a distance metric forthe advertised servers in a way that each router retains knowledge of atleast the nearest servers. In this way, each router in an internetworkhas enough knowledge to direct client requests to the nearest servers,without necessarily having to maintain knowledge of all the servers inthe internetwork. In another method, servers poll routers for thecontent of their routing tables. Guyton and Schwartz also describe amethod for gathering location data using routing probes without routersupport by means of measurement servers. According to this method,measurement servers explore the routes to the replicated serversproviding services and content to clients. When a client asks ameasurement server for a list of nearby servers from which to request aservice, the measurement server takes into account the route back to theclient in deciding the list of servers that appear closer to the client.

One approach to object discovery consists in organizing Web cacheshierarchically. In a hierarchical Web cache architecture, a parent-childrelationship is established among caches; each cache in the hierarchy isshared by a group of clients or a set of children caches. A request foran information object from a client is processed at a lowest-levelcache, which either has a copy of the requested object, or asks each ofits siblings in the hierarchy for the object and forwards the request toits parent cache if no sibling has a copy of the object. The processcontinues up the hierarchy, until a copy of the object is located at acache or the root of the hierarchy is reached, which consists of theservers with the original copy of the object.

One of the earliest examples of hierarchical Web caching was theDiscover system (A. Duda and M. A. Sheldon, “Content Routing in Networksof WAIS Servers,” Proc. IEEE 14th International Conference onDistributed Computing Systems,” June 1994; M. A. Sheldon, A. Duda, R.Weiss, J. W. O'Toole, Jr., and D. K. Gifford, “A Content Routing Systemfor Distributed Information Servers,” Proc. Fourth InternationalConference on Extending Database Technology, March 1994), which providesassociative access to servers; the user guides the refinement ofrequests.

Harvest (A. Chankhunthod, P. Danzing, C. Neerdaels, M. Schwartz, and K.Worrell, “A Hierarchical Internet Object Cache,” Proc. USENIX TechnicalConference 96, San Diego, Calif., January 1996) and Squid (D. Wessels,“Squid Internet Object Cache,” http://www.squid.org, August 1998) aretwo of the best known hierarchical Web cache architectures. Harvest andSquid configure Web caches into a static hierarchical structure in whicha Web cache has a static set of siblings and a parent. The InternetCaching Protocol or ICP (D. Wessels and K. Claffy, “Internet CacheProtocol (ICP), Version 2,” RFC 2186, September 1997) is used among Webcaches to request information objects.

In the Harvest hierarchies, siblings and parents are configured manuallyin Web caches or proxies; this is very limiting and error prone, becausereconfiguration must occur when a cache enters or leaves the system. Amore general limitation of hierarchical Web caching based on statichierarchies is that the delays incurred in routing requests forinformation objects can become excessive in a large-scale system, andthe latency of retrieving the information object from the cache with acopy of the object can be long, because there is no correlation betweenthe routing of the request to a given cache in the hierarchy and thenetwork delay from that cache to the requesting client. Furthermore,some Web caches may be overloaded with requests while others may beunderutilized, even if they store the same objects.

In the WebWave protocol (A. Heddaya and S. Mirdad, “WebWave: GloballyLoad Balanced Fully Distributed Caching of Hot Published Documents,”Technical Report BU-CS-96-024, Boston University, Computer ScienceDepartment, October 1996; A. Heddaya and S. Mirdad, “WebWave: GloballyLoad Balanced Fully Distributed Caching of Hot Published Documents,”Proc. IEEE 17th International Conference on Distributed ComputingSystems, Baltimore, Md., May 1997) Web caches are organized as a treerooted at the server that provides the original copy of one object or afamily of information objects; the leaves of the tree are the clientsrequesting the information objects, and the rest of the nodes in thetree are Web caches. The objective of the protocol is to achieve loadbalancing among Web caches; each Web cache in such a tree maintains ameasurement of the load at its parent and children in the tree, andservices or forwards the request to its parent automatically based onthe load information. This approach reduces the possibility ofoverloading Web caches as in the Harvest approach to hierarchical Webcaching; however, delays are still incurred in the propagation ofRequests from heavily loaded Web caches to their ancestors in the Webhierarchy.

Hash routing protocols (K. W. Ross, “Hash Routing for Collections ofShared Web Caches,” IEEE Network, Vol. 11, No. 6, November 1997, pp37-44) constitute another approach to support object discovery in sharedcaches. Hash routing protocols are based on a deterministic hashingapproach for mapping an information object to a unique cache (D. G.Thaler and C. V. Ravishankar, “Using Name-Based Mappings To IncreaseHit,” IEEE/ACM Trans. Networking, 1998; V. Valloppillil and J. Cohen,“Hierarchical HTTP Routing Protocol,” Internet Draft,http://www.nlanr.net/Cache/ICP/draft-vinod-icp-traffic-dist-00.txt) todistribute the information objects (universal resource locator or URL inthe case of the Web) among a number of caches; the end result is thecreation of a single logical cache distributed over many physicalcaches. An important characteristics of this scheme is that informationobjects are not replicated among the cache sites. The hash function canbe stored at the clients or the cache sites. The hash space ispartitioned among the N cache sites when a client requires access to aninformation object o, the value of the hash function for o, h(o), iscalculated at the client or at a cache site (in the latter case thecache would be configured at the client, for example). The value of h(o)is the address of the cache site to contact in order to access theinformation object o.

The Cache Resolver is another recent approach to hierarchical Webcaching (D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin, and R.Panigrahy, “Consistent Hashing and Random Trees: Distributed CachingProtocols for Relieving Hot Spots on the World Wide Web,” Proc. 29th ACMSymposium on Theory of Computing (STOC 97), El Paso, Tex., 1997; D.Karger, Sherman, A. Berkheimer, B. Bogstad, R. Dhanidina, K. Iwamoto, B.Kim, L. Matkins, and Y. Yerushalmi, “Web Caching with ConsistentHashing,” Proc. 8th International World Wide Web Conference, Toronto,Canada, May 1999). This approach combines hierarchical Web caching withhashing and consists of two main tools, random cache trees andconsistent hashing. A tree of Web caches is defined for each informationobject. When a browser (client) requires an information object, it picksa leaf of the tree and submits a request containing its identifier, theidentifier of the object, and the sequence of caches through which therequest is to be routed if needed. A Web cache receiving a request itdetermines if it has a local copy of the page and responds to therequest if it does; otherwise, it forwards the request to the next Webcache in the path included in the request. A Web cache startsmaintaining a local copy of an information object when the number ofrequests it receives for the object reaches a predefined number. Aclient selects a Web cache by means of consistent hashing, whichdisseminates requests to leaves of the Web caching hierarchy evenly but,unlike traditional hashing techniques, need not redistribute an updatedhash table every time a change occurs in the caching hierarchy (e.g., anew Web cache joins or a Web cache fails). Because caching is difficultto implement or add to existing Web browsers, the Cache Resolverapproach implements the hashing in DNS (Internet Domain Name Service)servers modified to fit this purpose. The remaining limitations withthis approach stem from the continuing use of a hierarchy of Web cachesand the need to implement a hashing function in either Web clients orDNS servers. Routing a request through multiple Web Caches can incursubstantial delays for clients to retrieve information objects that arenot popular among other clients assigned to the same Web cache by thehashing function. Additional delays, even if small, are incurred at theDNS server that has to provide the address of the Web cache that theclient should access. Furthermore, the DNS servers supporting theconsistent hashing function must receive information about the loadingof all the Web caches in the entire system, or at least a region of thesystem, in order to make accurate load-balancing decisions.

This DNS-based approach, without the use of hierarchies of Web caches,is advocated in the Akamai CDN solution (F. T. Leighton and D. M. Lewin,“Global Hosting System,” U.S. Pat. No. 6,108,703, Aug. 22, 2000). The“global hosting system” advocated by Akamai of Cambridge, Mass. assumesthat a content provider services an HTML document in which special URLsspecifying a domain name specific to Akamai. When the client needs toobtain the IP address of the Web cache hosting the content specified inthe special URL, the client first contacts its local DNS. The local DNSis pointed to a “top-level” DNS server that points the local DNS to aregional DNS server that appears close to the local DNS. The regionalDNS server uses a hashing function to resolve the domain name in thespecial URL into the address of a Web cache (hosting server) in itsregion, which is referred to as the target Web cache in the presentapplication, in a way that the load among Web caches in the region isbalanced. The local DNS passes the address of that Web cache to theclient, which in turn sends its request for the information object tothat Web cache. If the object resides in the target Web cache, the cachesends the object to the client; otherwise, the object is retrieved fromthe original content site.

The global hosting system advocated by Akamai was intended to addressproblems associated with traditional load-balanced mirroring solutionsin which a load balancer or a hierarchy of load balancers redirectrequests to one of a few hosting sites to balance the load among suchsites. Companies such as Cisco Systems of Santa Clara, Calif., F5Networks, Inc. of Seattle, Wash., Resonate, Inc. of Sunnyvale, Calif.,Nortel Networks of Brampton, Ontario, and Foundry Networks, Inc. of SanJose, Calif. currently provide examples of load-balanced solutions. Thelimitations of the global hosting system are inherent to the fact thatthe approach is, in essence, a DNS-based load-balanced mirroringsolution. The global hosting system selects a target Web cache basedentirely on the region that appears to favor the local DNS, which neednot favor the client itself, and balances the load among Web cacheswithout taking into account the latency between the Web caches and theclients. In the case of a cache miss, the information object has to beretrieved from the original content site, which means that latencies inthe delivery of content can vary widely, unless the content is mirroredin all the caches of all regions.

In summary, while these hierarchies and hash-based solutions provide asignificant improvement in effectiveness over their stand-alonepredecessors, they give rise to the following new dilemma: whileincreasing cache hit rates, and, thereby increasing the server andnetwork load, these solutions tend to increase the request latency seenby a Web client. Hierarchies increase the average number cache hopsneeded to reach an object, while hashing is insensitive to the distancebetween a client and the cache site it selects, which also increases theaverage number of hops needed to reach an object.

Another alternative approach to hierarchical web caching and hashrouting protocols consists of forwarding client requests for URLs usingrouting tables that are very similar to the routing tables used todayfor the routing of IP packets in the Internet (L. Zhang, S. Michel, S.Floyd, and V. Jacobson, “Adaptive Web Caching: Towards a New GlobalCaching Architecture,” Proc. Third International WWW Caching Workshop,Manchester, England, June 1998, B. S. Michel, K. Nikoloudakis, P.Reiher, and L. Zhang, “URL Forwarding and Compression in Adaptive WebCaching,” Proc. IEEE Infocom 2000, Tel Aviv, Israel, April 2000).According to this approach, which is referred to as “URL requestforwarding” herein, Web caches maintain a “URL request routing table”and use it to decide how to forward URL requests to other Web cacheswhen requested information objects are not found locally. The keys ofthe URL request routing tables are URL prefixes, which are associatedwith one or more identifiers to the next-hop Web caches or cache groups,and a metric reflecting the average delay to retrieve a request from amatching URL.

In this approach, an entry in the URL request routing table specifies aURL prefix and the next-hop Web cache towards an area or neighborhood ofWeb caches where the object resides. Ideally, a Web cache needs to knowwhere a copy of a given object resides; however, because of the largenumber of objects (identified by URLs) that can be requested in asystem, the URL request forwarding approach requires Web caches to beorganized into areas or neighborhoods. All Web caches within the samearea know the objects available in every other Web cache in the samearea. In addition, for those objects that are not found in the area of aWeb cache, the Web cache also maintains the next-hop Web cache towardsthe area in which a Web cache with the content resides.

Unfortunately, this approach has several scaling and performancelimitations. First, requiring each Web cache to know all the Web cacheswhere each object in the area resides incurs a large overhead, which isakin to the overhead of a traditional topology-broadcast protocol for IProuting, with the added disadvantage that the number of objects that canreside in an area can be much larger than the number of IP addressranges maintained in backbone routers of the Internet. Second, becauseWeb caches only know about the next hop towards a URL that does notreside in a region, a request for an object that lies outside the areaof a Web cache may traverse multiple Web-cache hops before reaching aWeb cache in the area where an object is stored. This introducesadditional latencies akin to those incurred in the caching hierarchiesproposed in other schemes discussed above. Third, it is difficult tomodify Web caches in practice to implement the mechanisms needed for theforwarding of URL requests.

To reduce the delays incurred in hierarchical Web caches, Tewari,Dahlin, Vin and Kay (R. Tewari, “Architectures and Algorithms forScalable Wide-area Information Systems,” Ph.D. Dissertation, Chapter 5,Computer Science Department, University of Texas at Austin, August 1998;R. Tewari, M. Dahlin, H. M. Vin, and J. S. Kay, “Design Considerationsfor Distributed Caching on the Internet,” Proc. IEEE 19th InternationalConference on Distributed Computing Systems, May 1999) introduce hintcaches within the context of a hierarchical Web caching architecture.According to this scheme, a Web cache maintains or has access to a localhint cache that maintains a mapping of an object to the identifier ofanother Web cache that has a copy of the object and is closest to thelocal hint cache. Web caches at the first level of the hierarchymaintain copies of information objects, while Web caches at higherlevels only maintain hints to the objects. Hints are propagated alongthe hierarchy topology from the Web caches lower in the hierarchy to Webcaches higher in the hierarchy. Furthermore, a Web cache with a copy ofan object does not propagate a hint for the object. The limitation withthis approach is that a Web caching hierarchy must still be established,which needs to be done manually in the absence of an automated method toestablish the hierarchy, and the Web caching hierarchy must match thelocality of reference by clients to reduce control overhead.

Another approach to reducing the latencies incurred with cachehierarchies consists of replacing the cache hierarchy with a directory(centralized or hierarchical) containing information about the objectskept at every cache. (Li Fan, Pei Cao, Jussara Almeida, and Andrei Z.Broder, “Summary cache: A scalable wide-area web cache sharingprotocol,” in Proceedings Sigcomm '98. ACM, October 1998.http://www.cs.wisc.edu/cao/papers/summarycache.html; Syam Gadde, MichaelRabinovich, and Jeff Chase, “Reduce, reuse, recycle: An approach tobuilding large internet caches,” in Proceedings 6th Workshop on HotTopics in Operating Systems, May 1997, Alex Rousskov and Duane Wessels,“Cache digests,” in Proceedings 3rd International WWW Caching Workshop,June 1998, http://wwwcache.ja.net/events/workshop/papers.html., RenuTewari, Michael Dahlin, Harrick M. Vin, and Jonathan S. Kay, “Designconsiderations for distributed caching on the internet,” Technicalreport, Department of Computer Sciences, University of Texas Austin,October 1998, http://www.cs.utexas.edu/users/UTCS/techreports/.) Thisdirectory is then used by a cache on a miss to determine the closestcache site holding the desired content. The limitations of thisdirectory-based approach is that the directory site(s) must receiveinformation about all caches in the system.

A number of proposals exist to expedite the dissemination of informationobjects using what is called “push distribution” and exemplified byBackweb, Marimba and Pointcast (“BackWeb: http://www.backweb.com/”;“Marimba: http://www.marimba.com/”; “Pointcast:http://www.pointcast.com/”). According to this approach, a Web serverpushes the most recent version of a document or information object to agroup of subscribers. The popular Internet browsers, Netscape andInternet Explorer, use a unicast approach in which the client receivesthe requested object directly from the originating source or a cache. Asthe number of subscribers of a document or information object increases,the unicast approach becomes inefficient because of processing overheadat servers and proxies and traffic overhead in the network. The obviousapproach to make push distribution scale with the number of subscribersconsists of using multicast technology. According to this approach (P.Rodriguez and E. W. Briesack, “Continuous Multicast Push of WebDocuments over The Internet,” IEEE Network Magazine, Vol. 12, No. 2, pp.18-31, 1998), a document is multicasted continuously and reliably withina multicast group. A multicast group is defined for a given Web documentand subscribers join the multicast group of the Web document they needto start receiving the updates to the document. A multicast groupconsist of the set of group members that should receive information sentto the group by one or multiple sources of the multicast group. The mainshortcoming of this particular approach to push distribution are thefollowing:

-   -   (1) the portion of the Internet where subscribers are must        support multicast routing distribution; and    -   (2) a multicast address and group must be used for each Web        document that is to be pushed to subscribers, which becomes        difficult to manage as the number of documents to be pushed        increases.

Furthermore, Rodriguez, Biersack, and Ross (P. Rodriguez, E. W.Biersack, and K. W. Ross, “Improving the WWW: Caching or Multicast?,”Institut EURECOM 2229, Route Computer Networks and ISDN Systems, pp.1-17 (Mar. 30, 1998) have shown that multicasting Web documents is anattractive alternative to hierarchical Web caching only when thedocuments to be pushed are very popular, caching distribution incursless latency.

Kenner and Karush (B. Kenner and A. Karush, “System and Method forOptimized Storage and Retrieval of Data on a Distributed ComputerNetwork,” U.S. Pat. No. 6,003,030, Dec. 14, 1999) propose a method forexpediting the delivery of information objects to end users. In thismethod, the end user site is equipped with special software in additionto the Web browser. This software consists of a configuration utilityand a client program. The configuration utility is used to download adelivery site file specifying a list of the delivery sites (Web cachesor originating Web servers) from which the information objects can beretrieved and a suite of tests that can be run to determine whichdelivery site to contact. The limitations with this approach stem fromthe fact that it is not transparent to end user sites. In particular,the end user site needs to run additional software; performance testsmust be conducted from the end-user site to one or more delivery sitesto decide which site to use; and when changes occur to the deliverysites, a new version of the delivery site file must be retrieved by theend-user site, or new performance tests must be conducted.

Another approach to helping select servers in a computer network (Z.Fei, S. Bhattacharjee, E. W. Zegura, and M. H. Ammar, “A Novel ServerSelection Technique for Improving The Response Time of a ReplicatedService,” Proc. IEEE Infocom 98, March 1998, pp. 783-791) consists ofbroadcasting server loading information after a certain load thresholdor time period is exceeded. The limitation of this approach is that,just as with topology-broadcast protocols used for routing in computernetworks, the scheme incurs substantial overhead as the number ofservers increases.

Another recent approach to directing clients to hosting sites withrequested information objects or services is the replica routingapproach proposed by Sightpath, Inc. (D. K. Gifford, “Replica Routing,”U.S. Pat. No. 6,052,718, Apr. 18, 2000). According to the ReplicaRouting approach, an information object or service is replicated in anumber of replica servers. The replica routing system redirects a clientrequesting the information object or service to a “nearby” replica ofthe object or service. In one approach, all replica routers know thereplica advertisements from each of the replica servers in the system,which summarize information about their location and observations aboutthe local internetwork topology and performance. Using this flooding ofadvertisements, a replica router discerns which replica server appearsnearby any one client. However, requiring each replica router to receivethe advertisements from every other replica server becomes impracticalas the number of replica servers and replica routers increases.

To remedy this problem, replica routers are organized into a hierarchy,and replica advertisements are propagated only part way up such routerhierarchy. A client request is routed to the root of the hierarchy andfrom there is forwarded down the hierarchy, until it reaches a replicarouter with enough knowledge about the replica's internetwork locationto make an informed redirection decision. This approach has similarperformance and scaling limitations as the prior approaches summarizedabove based on hierarchies of Web caches, flooding of information amongcaches or servers, and forwarding of requests over multiple hops.

Another recent approach to directing clients to hosting sites withrequested information objects or services is the enhanced networkservices method by Phillips, Li, and Katz (S. G. Phillips, A. J. Li, andD. M. Katz, “Enhanced Network Services Using a Subnetwork ofCommunicating Processors,” U.S. Pat. No. 6,182,224, Jan. 30, 2001.).Insofar as directing clients to servers, the enhanced network servicesmethod is very similar to the gathering of location data with routersupport advocated by Guyton and Schwartz described previously. As in theGuyton and Schwartz's approach, routers using the enhanced networkservices approach gather network topological data and also include aspart of their normal routing exchanges information about the hosts thatcan provide content and services to clients; routers can then rank thehosts according to their relative distance in the network. In additionto data regarding hosts that can provide services, routers in theenhanced network services approach can include in their normal routingexchanges host information regarding logged-in users and willingness topay for performing a designated service. In contrast to the proposal byGuyton and Schwartz, the enhanced network services approach does notattempt to limit the amount of network topological information thatrouters need to exchange in order to direct clients to best qualifiedservers. This approach has, therefore, similar performance and scalinglimitations as the prior approaches summarized above based on floodingof information among caches or servers, and forwarding of requests overmultiple hops.

SUMMARY OF THE INVENTION

In one embodiment, a request for an information object at an addressidentified by a uniform resource locator (URL) is received; and the URLis mapped to a corresponding anycast address for the information object.Thereafter, the anycast address for the information object may beresolved to a unicast address for the information object, and theinformation object sent to the client. The request may be received at aninformation object repository that is topologically closer to the clientthan any other information object repository. This closest informationobject repository may be selected according to specified performancemetrics, such as: average delay from the selected information objectrepository to a source of the request, average processing delay at theselected information object repository, reliability of a path from theselected information object repository, available bandwidth in saidpath, and loads on the selected information object repository.

A further embodiment provides an information object repositoryconfigured to map a uniform resource locator (URL) for an informationobject to a network layer anycast address. The anycast address may thenbe advertised using a network layer anycast routing protocol.

Still another embodiment provides a network, having at least one clientconfigured to request an information object using a uniform resourcelocator (URL); and an information object repository configured toreceive the request for the information object and to map the URL into anetwork layer anycast address. The information object repository may befurther configured to resolve the network layer anycast address into aunicast address. This information object repository is preferablytopologically closer to the requesting client than any other of a numberof information object repositories in the network. A Web router may beconfigured to select the information object repository that is closer tothe requesting client than any other of the number of information objectrepositories in the network without regard as to whether the informationobject is actually stored at the selected information object repository.For example, such selection may be made according to specifiedperformance metrics, such as: average delay from the selectedinformation object repository to a source of the request, averageprocessing delay at the selected information object repository,reliability of a path from the selected information object repository,available bandwidth in said path, and loads on the selected informationobject repository.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and notlimitation, in the figures of the accompanying drawings in which:

FIG. 1 illustrates a conventional internetwork, such as the Internet;

FIG. 2 illustrates a network having a virtual topology of Web routersconfigured in accordance with an embodiment of the present invention;

FIG. 3 illustrates one example of the interconnection of Web routers andcache servers with each other and a farm of redirectors usingconventional IP routers in accordance with one embodiment of the presentinvention;

FIG. 4 is a flowchart illustrating a method of configuring an anycastcache server in a network upon the loading of content for a URL onto theanycast cache server in accordance with an embodiment of the presentinvention; and

FIG. 5 is a flowchart of a method of sending, from an anycast cacheserver, content to a client according to one embodiment of the presentinvention.

DETAILED DESCRIPTION

Various methods and systems for using network layer uniform resourcelocator (NURL) routing to find topologically close information objectrepositories (e.g., a server or other content source) storing specifiedinformation objects (i.e., content) are disclosed herein. Such methodsand systems may find application in networks configured to controlaccess to information objects (i.e., content) carried in informationobject repositories (i.e., caches, proxies, origin content servers andthe like) and/or to support delivery of such information objects. Theinformation objects and/or information object repositories storing theinformation objects may be distributed over one or more computernetworks or networks of networks. In the following description, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be evident tothose of ordinary skill in the art that some of these specific detailsneed not be used to practice the present invention and/or thatequivalents thereof may be used. In other cases, well-known structuresand components have not been shown in detail to avoid unnecessarilyobscuring the present invention. Thus, although discussed with referenceto certain illustrated embodiments, upon review of this specification,those of ordinary skill in the art will recognize that the presentsystem and methods may find application in a variety of systems and theillustrated embodiments should be regarded as exemplary only and shouldnot be deemed to be limiting in scope.

Some portions of the description that follow are presented in terms ofalgorithms and symbolic representations of operations on data within acomputer memory (e.g., in flow chart format). These algorithmicdescriptions and representations are the means used by those skilled inthe computer science arts to most effectively convey the substance oftheir work to others skilled in the art. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of steps leadingto a desired result. The steps are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers or the like. It should be borne inmind, however, that all of these and similar terms are to be associatedwith the appropriate physical quantities and are merely convenientlabels applied to these quantities. Unless specifically statedotherwise, it will be appreciated that throughout the description of thepresent invention, use of terms such as “processing”, “computing”,“calculating”, “determining”, “displaying” or the like, refer to theaction and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system's registersand memories into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

In accordance with one embodiment of the present invention, a collectionof one or multiple “Web routers” is used to refer a request for anobject to a Web cache or content server (or other information objectrepository) that is able to transfer the requested object to the targetclient while satisfying a given set of performance metrics. Note, thisreferral may be made without regard as to whether the designatedinformation object repository actually includes the requestedinformation object(s). As used herein, the term Web router is used torefer to an embodiment (which may be implemented in hardware and/orsoftware to be executed by a computer system) of a computer systemconfigured in accordance with the methods (described below) needed tomap the address of a client with the address of a Web cache that candeliver requested information objects optimally to the client. Theperformance metrics used by Web routers to choose the sites (Web cacheor content server) that should provide the requested objects to theclients can include network delays, available bandwidth, reliability ofpaths from the chosen sites to the target clients, and loads on the Webcaches and content servers. The method used to select the best site fromwhich information objects should be retrieved is transparent to theclients, and the computer network or internetwork over which the systemoperates need not support multicast delivery to end-user sites.

A Web router may be co-located with a Web server, a Web cache, a hostingserver, a DNS server or an original content server. A topology of Webrouters is defined such that a given Web router has as its neighbor Webrouters a subset of all the Web routers in the system. A Web routercommunicates directly with its neighbor Web routers, and, preferably,not with other Web routers.

In one embodiment of the present invention, a Web router is contactedaccording to a scheme for enabling the discovery of the caches andservers storing information objects distributed over computer networks,which can be implemented in hardware and/or software, by a client, a Webserver, a Web cache, or another type of server with a request for theaddress of one or more Web caches that a client should contact to obtainan information object. Further descriptions of these various schemes arepresented below. A complete description of a Web router is included inco-pending U.S. patent application Ser. No. 09/810,148, entitled “Systemand Method for Discovering Information Objects and Information ObjectRepositories in Computer Networks”, filed Mar. 15, 2001, the completedisclosure of which is incorporated by reference herein.

By utilizing the Web router concept, the present invention approachesthe challenge of providing an efficient, scalable, server-directed Webcontent delivery system from a network layer perspective. Further, thepresent invention provides efficiency and scalability at least as goodas that of the underlying infrastructure technologies. In oneembodiment, the present invention includes routing technologies that maybe used to leverage the underlying network routing to provide optimalselection of cache sites and content distribution paths, for examplethrough the use of transport-layer protocols which may be used to makethe most efficient use of network resources for content delivery. Theseprotocols may also include signaling and congestion avoidance mechanismswhich may be used to further optimize the use of network resources tolevels of effectiveness and efficiency beyond that typically provided byunderlying infrastructure services.

FIG. 1 illustrates an internetwork 100. The methods and systemsdescribed herein, which can be implemented in software and/or hardware,enable the discovery of either information objects or the caches andservers storing information objects distributed over computer networkssuch as the internetwork 100 shown in this illustration. One example ofan internetwork 100 is the Internet. Other examples include enterprisenetworks, local area networks, wide area networks, metropolitan areanetworks and networks of such networks. In the case where internetwork100 is the Internet, clients 105 will generally access content locatedat remote servers 150 through a series of networks operated by differentproviders. For example, clients 105 may have accounts with localInternet service providers (ISPs) 110 that enable the clients to connectto the Internet using conventional dial-up or one of a variety ofhigh-speed connections (e.g., DSL connections, cable connections,hybrids involving satellite and dial-up connections, etc.). ISPs 110, inturn, may provide direct connections to the Internet or, as shown, mayrely on other service providers 120, 130, 140, to provide connectionsthrough to a set of high-speed connections between computer resourcesknown as a backbone 150. Connecting to a host (e.g., server 150) maythus involve connecting through networks operated by a variety ofservice providers.

Overview of Minimizing Latency on Cache Hits

In one embodiment, one component of the present invention involvesminimizing the latency of cache hits. Concretely this translates intominimizing the topological distance between the Web client and the cacheserver. In an exemplary embodiment, two mechanisms are defined in thearchitecture of the present invention for this purpose:

-   -   (1) one mechanism for use in initially establishing the Web        client to cache server connection; and    -   (2) the other mechanism for use in providing continuous        adjustment of this connection in response to changing network        conditions.

As explained above, optimal cache selection is achieved through the useof Web routers. In an exemplary embodiment, the present inventionattempts to allow the Web client to begin downloading content from acache server offering the lowest latency.

FIG. 2 illustrates a virtual network 200 of Web routers 202-216 definedon top of the physical topology of an internetwork, such as theInternet, consisting of routers interconnected via point-to-point linksor networks. The virtual network 200 of Web routers includespoint-to-point links configured between the Web routers 202-216, and thelinks configured between a Web router (e.g., Web router 202) and one ormore Web caches (e.g., Web cache 218) and content servers (e.g., contentserver 220). Such links can be implemented using tunnels between Webrouters and between Web routers and Web caches. As used herein, the termcontent server is meant to indicate a server that serves as theorigination point for a piece of content (e.g., text, video, audio,etc.). Such content may subsequently be replicated at one or more Webcaches. As shown in the figure, a client 105 is not necessarily part ofthe virtual network of Web routers.

As indicated above, a Web router is one embodiment of the methodsdescribed herein for discovering information objects and objectrepositories in computer networks. The functionality of a Web router canbe implemented as part of a Web cache, as part of a router, or as aseparate entity. To simplify its description, the Web router isdescribed and treated herein as a separate entity from a Web cache or arouter.

A Web router may be co-located with a Web server, a Web cache, or anoriginal content server. In one embodiment of the present invention, aWeb router may be implemented in software to be executed by ageneral-purpose (or special purpose) computer processor, or it may beimplemented as part of the software of a router or Web cache. In anotherembodiment of the present invention, some or all of the Web routerfunctionality may be implemented in hardware.

In a preferred embodiment of the present invention, a collection of oneor multiple Web routers is used to refer the request for an object to aWeb cache or the content server that is able to transfer the requestedobject to the target client while satisfying a given set of performancemetrics. The performance metrics used by Web routers to pick the sites(Web cache or content server) that should provide the requested objectsto the clients are called type-of-service (TOS) parameters and include,but are not limited to, network delays, bandwidth available, reliabilityof paths from the chosen sites to the target clients, and loads on theWeb caches and content servers. The value of the TOS parameters of thepath from a server or Web cache to a client is called the TOS distanceof such a server or Web cache to the client. The technique used toselect the best site from which information objects should be retrievedby user sites (clients) is transparent to the user sites, and thecomputer network or internetwork over which the system operates need notsupport multicast delivery to end-user sites.

To reduce communication and processing overhead in Web routers, atopology of Web routers is defined, such that a given Web router has asits neighbor Web routers a subset of all the Web routers in the system(where the term system refers to all or a portion of the virtual networkfor Web routers discussed above). A Web router may thus be configuredwith its set of neighbor Web routers. Such a configuration may be atable of neighbor Web routers which is defined by a network serviceprovider and/or is dynamically updated. In another embodiment of thepresent invention, a Web router dynamically selects the set of neighborWeb routers with which it should communicate out of all of the Webrouters in the system. A Web router preferably communicates with itsneighbor Web routers only and uses the Web Information Locator byDistance (WILD) protocol for this purpose. The WILD protocol isdisclosed in co-pending and commonly-owned U.S. Provisional ApplicationNo. 60/200,401, filed Apr. 28, 2000, from which U.S. patent applicationSer. No. 09/810,148, filed Mar. 15, 2001 (now U.S. Pat. No. 7,162,539B2, issued Jan. 9, 2007) claims priority.

In one embodiment of the present invention, WILD runs on top of theTransmission Control Protocol (TCP) in much the same way as the BorderGateway Protocol (BGP) does. In this embodiment, a TCP connection existsbetween a Web router and each of its neighbor Web routers. In anotherembodiment of the present invention, WILD can run on top of the TCPSanta Cruz protocol [C. Parsa and J. J. Garcia-Luna-Aceves, “TCP-SantaCruz: Improving TCP Performance over Networks with HeterogeneousTransmission Media”, Proc. IEEE ICNP 99], which is disclosed incommonly-owned U.S. Provisional Application No. 60/190,331, filed onMar. 16, 2000, from which U.S. patent application Ser. No. 09/810,148,filed Mar. 15, 2001 (now U.S. Pat. No. 7,162,539 B2, issued Jan. 9,2007) claims priority. Other embodiments of the present invention may bebased on alternative protocols for the provision of reliabletransmissions between Web routers.

In one example of the operation of a system which employs an embodimentof the present invention, a client first contacts a Web serverrequesting a Web page in which a set of information objects arereferenced by their URLs. In turn, the Web server may contact a Webrouter to determine the sites (e.g., one or more Web cache(s) or anoriginal content server, any of which may be referred to generically asan information object repository) from which each of such informationobjects should be retrieved. Depending on the implementation, a Webrouter can be contacted by a client, a Web cache, a content server, oranother type of server (e.g., Web server 222 or 224), asking for theaddress of a Web cache, set of Web caches, or content server that aclient should contact for the purposes of retrieving informationobjects. In the present example, the Web server provides the Web routerwith the address of the client requesting the set of object, a URL foreach information object requested by the client, and a set of TOSparameter values with which the request should be serviced to theclient. The absence of TOS parameters can be assumed to imply aminimum-delay service request.

Those Web routers that are used to redirect clients to appropriate Webcaches or content servers are implemented in a very fault-tolerantmanner and are well known throughput the system. Accordingly, in oneembodiment, not all Web routers in a system are used for clientredirection in order to reduce the cost of Web routers and thecommunication overhead associated with knowing about the existence ofWeb routers that are capable of redirecting clients to Web caches andcontent servers. Thus, a network may include a set of redirecting Webrouters.

The set of redirecting Web routers should be known by all the Webrouters of the system, while a Web router that does not serve as aredirecting Web router need not be known by all other Web routers of thesystem. Web routers may execute WILD (or another protocol) to map theaddress of a client into: (a) one or more addresses of Web caches or thecontent server that has the best TOS distance to the client address, and(b) one or more addresses of redirecting Web routers that have the bestTOS distance to the client address. In some cases, this mapping is doneindependently or regardless of whether the Web cache or content servermaintains a local copy of any of the information objects required by theclient (the idea being that the content can be brought to the cacheafter the client has been advised of the “best” or “preferred” cache toconnect to).

As indicated, Web routers may use WILD or a non-WILD protocol toaccomplish the above mappings. For example, in one embodiment, Webrouters may use a static, fixed mapping of the address of a client into:(a) one or more addresses of Web caches or the content server that hasthe best TOS distance to the client address, and (b) one or moreaddresses of redirecting Web routers that have the best TOS distance tothe client address. Such static, fixed mappings may be input by a useror a network service provider and may or may not be updatedperiodically. The static, fixed mappings may be generated by WILD or byan algorithm other than WILD. In either case, the static, fixed mappingsmay be generated independently of whether the Web cache or contentserver maintains a local copy of any of the information objects requiredby the client.

In one embodiment of the present invention, the Internet routers of thesystem provide Web routers with distances to known destination addressesmeasured according to a number of network performance parameters. A Webrouter collocated with a Web cache or content server uses theinformation obtained from adjacent routers and the performancemeasurements of the Web cache or content server to derive the TOSdistance from the collocated Web cache or content server to each knowndestination, which corresponds to potential client addresses. In oneembodiment, Web routers use routing information provided by the BorderGateway Protocol (BGP) and any of the intra-domain routing protocols(e.g., OSPF, EIGRP) running in the routers attached to the same localarea networks where the Web routers reside to derive distances to clientaddress ranges (e.g., using a shortest-path first calculation).

Regardless of how the actual mapping is done (e.g., whether using WILDor another algorithm), if a Web router maps the address of the clientrequiring the location of information objects to addresses of Web cachesor other information object repositories that do not currently storesuch objects, the Web router can request the corresponding Web caches toobtain a copy of the required objects immediately after it provides therequesting Web server the address of such a Web cache or proxy. Inanother embodiment, a Web cache or proxy attempts to retrieve arequested object from another Web cache or a content server only afterit is contacted by a client and determines that a copy of the requestedinformation object is not available locally. In both instances, the Webrouter provides the Web cache servicing a client request with theaddress of the “nearest” Web cache that stores the information objectrequested by the client; therefore, the Web cache needing theinformation object communicates directly with the Web cache storing therequested information object, without having to go through anyintermediate Web caches and without having to know the content stored inall other Web caches as is customary in the prior art.

Building on the above then, the Web router is responsible fordetermining which of a number of available information objectrepositories should service a client (i.e., a client or a Web serverrequest for an information object or service). The Web router alsodetermines the information object repository which actually maintainsthe information object or service so requested, and initiates theprocess of bringing the information object or service to the informationobject repository that should service the client. Bringing theinformation object or service requested by the client to the informationobject repository which it has been determined should service the clientrequest is accomplished, in one embodiment, by instructing thatinformation object repository which will service the request to retrievethe information object or service requested by the client from theinformation object repository which actually maintains the informationobject or service. Thereafter, upon receiving an instruction to do so,the information object repository which it has been determined shouldservice the client request contacts the information object repositorythat actually maintains the information object or service requested bythe client directly to request the information object or service.

In a further embodiment, one of the following four mechanisms, or, acombination of some of the following four mechanisms, is or may be usedto communicate the best Web cache or content server, or the set of Webcaches (more generally the information object repository(ies)), whichshould serve a client's request:

-   -   (1) direct cache selection;    -   (2) redirect cache selection;    -   (3) remote DNS cache selection; and    -   (4) client DNS cache selection.        These approaches are described in detail in co-pending U.S.        Provisional Patent Application No. 60/200,404, entitled “System        and Method for Using a Mapping Between Client Addresses and        Addresses of Caches to Support Content Delivery”, filed Apr. 28,        2000, and U.S. patent application Ser. No. 09/843,789, entitled        “System and Method for Using a Mapping Between Client Addresses        and Addresses of Caches to Support Content Delivery”, filed Apr.        26, 2001, the complete disclosure of which is incorporated        herein by reference.        Dynamic Congestion Adaptation During Content Download

In some cases, after the initial client-server connection isestablished, and a download is in progress, continuous monitoring andadjustment of the connection is performed to adjust to changing networkconditions. This may be especially important for larger content (i.e.,large files), such as streaming media, which may require an extendedperiod to download. During such long downloads, network conditions maychange sufficiently such that the path from the initial cache server tothe client degrades to an unacceptable state. To avoid this situation,in one embodiment, the cache servers constantly (or periodically)monitor and adjust existing connections. In the event performance on anexisting connection appreciably degrades, the cache servers may begin aprocess of searching for other cache servers with significantly betterpaths to the client. If such a server is found the download istransferred to the new cache, and the process is repeated. Anotherembodiment may include a dynamic redirector selection at the Web server.

Overview of Minimizing Latency on Cache Misses

In one embodiment, another component of the present invention includes aset of technologies that minimize the latency of cache misses. Thus, ona cache miss the selected cache server locates the closest cache serverwith a copy of the desired content and downloads the content from thatserver as fast and efficiently as possible. As explained above, this maybe performed in parallel with the requesting client being informed ofthe IP address of the cache server which is obtaining the content.

Network-Layer URL Routing

In one embodiment, as illustrated in FIG. 3, the present inventionincludes pairs of Web routers 302 and cache servers 304 interconnectedwith each other and a farm of redirectors 300 by conventional IP routers306. In such cases, this component of the present invention exploits theIP routing infrastructure to provide, in effect, routing of URLs.

Network-layer URL (NURL) routing involves mapping requested URLs tounicast addresses which may then used as an anycast IP address (i.e. aunicast address advertised by multiple, physically distinct points in aninternet) [Craig Partridge, Trevor Mendez, and Walter Milliken, “Hostanycasting service”, RFC 1546, November 1993]. In Internet ProtocolVersion 6 (IPv6), anycast is communication between a single sender andthe nearest of several receivers in a group. The term exists incontradistinction to multicast, communication between a single senderand multiple receivers, and unicast, communication between a singlesender and a single receiver in a network. Anycasting is designed to letone host initiate the efficient updating of router tables for a group ofhosts. IPv6 can determine which gateway host is closest and sends thepackets to that host as though it were a unicast communication. In turn,that host can anycast to another host in the group until all routingtables are updated. A system and method for using uniform resourcelocators (URLs) to map application layer content names to network layeranycast addresses, is disclosed in co-pending and commonly-owned U.S.Provisional Application Ser. No. 60/200,511, entitled “System and Methodfor Using URLs to Map Application Layer Content Names to Network LayerAnycast Addresses”, filed Apr. 28, 2000.

In order to facilitate this mapping, content served by the presentinvention are assigned URLs having the following format:

-   -   http://<Redirector IP>/<URL Anycast IP>/<URL Multicast IP>.        From such a URL, the anycast IP address can be determined (the        use of the multicast address is explained below). For example,        upon loading content for a URL, a certain type of cache server,        called an anycast cache server, may advertise a route for the        URL's IP address using the network-layer unicast routing        protocol [see, e.g., Gary Scott Malkin, “Rip version 2”, RFC        2453, November 1998; John Moy, “Ospf version 2”, RFC 2328, April        1998]. In order to encourage the use of less loaded cache        servers, in one embodiment, the distance for the advertised        route is initialized to a value that is a function of the cache        server's load (instead of the normal initial distance of zero).        The processing of this routing advertisement by the routing        protocol results in each router in the network computing the        route to the closest server holding the content identified by        the IP address.

FIG. 4 is a flowchart of a method 400 of configuring an anycast cacheserver in a network upon the loading of content for a URL onto theanycast cache server according to one embodiment of the presentinvention. As discussed above, the loading of content for a URL triggersthe happening of certain configuration steps. In step 402, the anycastcache server receives a request to register the URL (i.e., the URL thatis associated with the requested content) in the network routing layer.In response to this request, in step 404, the anycast cache server mapsthe URL to a network layer anycast address. In step 406, a local stateis created that is adequate for accepting future anycast requests. Instep 408, the anycast cache server advertises a route to the anycast IPaddress with network layer unicast routing. In decision operation 410,it is determined whether further requests can be received at the anycastcache server. If further requests can be received, the process resetsand executes again. On the other hand, if no further requests can bereceived, the process quits.

With the route to the anycast cache server existing in the networkinfrastructure, a cache server processing a cache miss would like totransfer the content from the URL IP address. In an exemplaryembodiment, in such a situation, the present invention resolves theanycast address to the server's real unicast address (which, bydefinition, uniquely identifies that server in the internet) beforestarting the download. In an exemplary embodiment, this is done by usingan anycast address resolution protocol (AARP), which is disclosed inco-pending and commonly-owned U.S. Provisional Application Ser. No.60/200,403, filed Apr. 28, 2000, which is incorporated herein byreference.

FIG. 5 is a flowchart of a method 500 of sending, from an anycast cacheserver, content to a client according to one embodiment of the presentinvention. This method addresses the aforementioned problems that may beassociated with using the anycast IP address while downloading contentfrom the cache server to the client. As discussed above, a redirectorWeb router provides the client with the appropriate information neededto access the topologically closest cache server that contains therequested content. In step 502, the closest cache server receives arequest for content given a URL. In response to this request, in step504, the cache server maps the URL to a network layer anycast IPaddress. At this point, it is desirable to resolve the anycast IPaddress into a unicast address. Accordingly, in step 506, it isdetermined whether the anycast IP address can be resolved into a unicastaddress. If the anycast IP address cannot be resolved, in step 508, thecache server returns a failure. In other words the cache server notifiesthe client that the anycast IP address could not be resolved into aunicast address. As discussed above, when a cache server is actuallysending content and then a mid-stream change in destinations occurs, thedownloading of the requested content will fail.

If the anycast address can be resolved, in step 510, the anycast IPaddress is resolved into a unicast address. In step 512, the unicastaddress is used to locate and send the requested content to the client.In decision operation 514, it is determined whether further requests canbe received at the cache server. If further requests can be received,the method returns to step 502. On the other hand, if no furtherrequests can be received, the process quits.

CONCLUSION

The present invention provides a system and method for using networklayer uniform resource locator routing to find a topologically closeinformation object repository storing a specified information object. Inone embodiment, the present invention is part of a method and system forthe discovery of information objects and servers storing informationobjects distributed over computer networks. Having fully describedvarious preferred embodiments of the invention and various alternativesthereto, it should be recognized that numerous alternatives andequivalents exist which do not depart from the invention. Accordingly,the invention should only be measured in terms of the claims, whichfollow.

1. A method, comprising: receiving, at an information object repository,a request from a client for an information object at an addressidentified by a uniform resource locator (URL); mapping the URL to acorresponding anycast address for the information object, wherein theinformation object repository is selected according to specifiedperformance metrics by mapping an address of the client to one or moreaddresses of information object repositories and to one or moreaddresses of routers that have a best type-of-service distance to theaddress of the client, wherein the mapping the address of the client tothe one or more addresses of information object repositories and to theone or more addresses of routers is performed by executing a WebInformation Locator by Distance (WILD) communication protocol betweenthe routers that store one or more first type-of-service distances fromone or more information object repositories to the address of the clientand one or more second type-of-service distances from one or morerouters to the address of the client, wherein the routers communicate toeach other WILD update messages to update mapping of client addressranges to the addresses of Web caches and redirecting routers, whereinWILD update message includes a basic routing table, a list oftype-of-service distances from the Web caches to destinations, and alist of type-of-service distances from the redirecting routers to thedestinations, wherein the WILD communication protocol runs on top of aTransmission Control Protocol (TCP); determining whether the anycastaddress can be resolved into a real unicast address that is uniquelyidentified for the information object in the Internet; resolving theanycast address for the information object to the unicast address forthe information object, if the corresponding anycast address can beresolved into the unicast address, wherein resolving the anycast addresscomprises sending an anycast resolution query to the anycast addressaccording to an anycast address resolution protocol (AARP); returning afailure if the anycast address cannot be resolved into the unicastaddress; and obtaining a copy of the information object using theresolved unicast address.
 2. The method of claim 1 further comprisingsending the information object to the client.
 3. The method of claim 2wherein the request is received at an information object repository thatis topologically closer to the client than any other information objectrepository.
 4. The method of claim 3 wherein the information objectrepository is selected according to specified performance metrics. 5.The method of claim 4 wherein the performance metrics comprise one ormore of: average delay from the selected information object repositoryto a source of the request, average processing delay at the selectedinformation object repository, reliability of a path from the selectedinformation object repository, available bandwidth in said path, andloads on the selected information object repository.
 6. An informationobject repository comprising: a memory to store one or more firsttype-of-service distances from one or more information objectrepositories to an address of a client and one or more secondtype-of-service distances from one or more routers to the address of theclient; and a processor configured to map a uniform resource locator(URL) for an information object to a network layer anycast address,wherein the information object repository is selected according tospecified performance metrics by mapping the address of the client toone or more addresses of the information object repositories and to oneor more addresses of the routers that have a best type-of servicedistance to the address of the client, wherein the processor isconfigured to map the address of the client to the one or more addressesof information object repositories and to the one or more addresses ofrouters by executing a Web Information Locator by Distance (WILD)communication protocol that includes communicating to neighboringrouters WILD update messages to update mapping of client address rangesto the addresses of Web caches and redirecting routers, wherein a WILDupdate message includes a basic routing table, a list of type-of-servicedistances from the Web caches to destinations, and a list oftype-of-service distances from the redirecting routers to thedestinations and receiving, from the neighboring routers, the WILDupdate messages, wherein the WILD protocol runs on top of a TransmissionControl Protocol (TCP); to determine whether the network layer anycastaddress can be resolved into a real unicast address that is uniquelyidentified for the information object in the Internet, to resolve theanycast address for the information object to a unicast address for theinformation object, if the anycast address can be resolved into theunicast address; to send an anycast resolution query to the anycastaddress according to an anycast address resolution protocol (AARP), toreturn a failure if the anycast address cannot be resolved into theunicast address; and to obtain a copy of the information object usingthe resolved unicast address.
 7. The information object repository ofclaim 6 being further configured to advertise the anycast address usinga network layer anycast routing protocol.
 8. A network, comprising: atleast one client configured to request an information object using auniform resource locator (URL); a plurality of routers having storagemeans for storing one or more first type-of-service distances from oneor more information object repositories to an address of a client andone or more second type-of-service distances from one or more routers tothe address of the client; and an information object repositoryconfigured to receive the request for the information object and to mapthe URL into a network layer anycast address, wherein the informationobject repository is selected according to specified performance metricsby mapping an address of the client to one or more addresses ofinformation object repositories and to one or more addresses of therouters that have a best type-of-service distance to the address of theclient, wherein the mapping the address of the client to the one or moreaddresses of information object repositories and to the one or moreaddresses of the routers is performed by executing a Web InformationLocator by Distance (WILD) communication protocol between the routers,wherein the routers communicate to each other WILD update messages toupdate mapping of client address ranges to the addresses of Web cachesand redirecting routers, wherein a WILD update message includes a basicrouting table, a list of type-of-service distances from the Web cachesto destinations, and a list of type-of-service distances from theredirecting routers to the destinations, wherein the WILD communicationprotocol runs on top of a Transmission Control Protocol (TCP), todetermine whether the network layer anycast address can be resolved intoa real unicast address that is uniquely identified for the informationobject in the Internet; to resolve the network layer anycast addressinto the unicast address if the network layer anycast address can beresolved into the unicast address, to send an anycast resolution queryto the anycast address according to an anycast address resolutionprotocol (AARP), to obtain a copy of the information object using theresolved unicast address and to return a failure if the anycast addresscannot be resolved into the unicast address.
 9. The network of claim 8wherein the information object repository is topologically closer to theclient than any other of a number of information object repositories inthe network.
 10. The network of claim 9 further comprising a Web routerconfigured to select the information object repository that is closer tothe requesting client than any other of the number of information objectrepositories in the network without regard as to whether the informationobject is actually stored at the selected information object repository.11. The network of claim 10 wherein the Web router is further configuredto select the selected information object repository according tospecified performance metrics.
 12. The network of claim 11 wherein theperformance metrics comprise one or more of: average delay from theselected information object repository to a source of the request,average processing delay at the selected information object repository,reliability of a path from the selected information object repository,available bandwidth in said path, and loads on the selected informationobject repository.